System for providing remote expertise

ABSTRACT

Expertise, such as foreign language interpretation, is delivered to requestors by an expertise-provisioning system that brokers requests between the requestors and experts affiliated with virtual call centers.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of U.S. patent application Ser. No.15/233,389, filed Aug. 10, 2016, which claims the benefit of provisionalapplication Ser. No. 62/203,593, filed Aug. 11, 2015, the disclosure ofwhich is hereby incorporated by reference as though fully set forthherein.

BACKGROUND

Advances in automated access to remote expertise have made resourceslike foreign language interpreters and health coaches more readilyavailable to people who need such access.

SUMMARY

Although the current model by which real-time expertise is provided tothose who need it has enjoyed acceptance in the marketplace, the presentinventor has recognized that improvements are desirable and anexpertise-provisioning system disclosed herein provides thoseimprovements.

One problem in the prior art is that it is difficult for organizationsneeding timely access to expertise, such as language interpretation, tofully and/or effectively utilize in-house resources, such as staffinterpreters. For example, hospitals might have staffers with “regular”healthcare duties as nurses, aides, administrators but who have foreignlanguage expertise and are on-call to help care-givers communicate withnon-English speaking patients.

Use of such staffers for interpretation has, however, proven to besomewhat hit-or-miss because they may be unable to deliver theirexpertise in a timely manner due to logistics challenges, particularlyoutside of the hospital. Addressing that issue by hiring full-timeinterpreters is usually not an effective solution because there may wellnot be enough demand for interpretation and/or because there may be noin-house expertise in a given language spoken by a particular patient.The resulting situation may cause a hospital or other organization inneed of, say, interpretation expertise to contract with a third-partyinterpretation service. Such services provide 24-hour coverage and cancall on experts anywhere in the world to provide interpretation for avast array of languages, many of which are rarely encountered. Theservice, either manually or through computerization, attempts to locateand available one of its experts and then instantiates a connectionbetween the request and expert accessed by telephone or video link.Unfortunately, then, the hospital will have foregone the opportunity touse in-house interpretation expertise that might be readily available atthe time its needed, thereby losing the opportunity to enjoy thefinancial benefits of using in-house staff who, as salaried employeesproviding other functions within the hospital, do not have to be paidanything additional to provide interpretation as may be needed.

Another problem relates to the technology typically used to deliverlanguage interpretation services or other expertise. Services such asthose just mentioned typically employ rigid communication networkscreated by existing technology vendors that prioritize serving up theirown personnel or affiliates for a fee. This can result in aless-than-satisfactory ability to dynamically provision the rightexpertise to the right patients in real time. Moreover, existingtechnology such as dual-handset phones or video conferencing systemsoften rely on proprietary hardware, special network configurations andhosted software. Even in cases where these constraints are transparentto the end user, there is a significant cost in terms of both effort andmoney to put these systems in place and maintain them. In most cases,these systems exist outside the context of care delivery—forcing careproviders to take additional steps to access remote expertise such asfetching a special terminal to make a video call.

In many cases, especially when video is involved, a conference roomapproach is used where both parties are given a virtual room number tojoin, instead of being directly connected. In any case, there is noability for these systems to automatically adapt to changes in thelandscape of available experts or requirements of the requestor

Another problem is timeliness of the delivery of the requestedexpertise. The experts employed by the contracted-with service providermay be busy, leading to long wait times, and/or no remote expert withthe necessary expertise (e.g. a language spoken by relatively fewpeople) may be available at all. Clients could, of course, contract withmultiple services, thereby increasing their chances of finding a remoteexpert who is currently available but having to access multipleproviders seriatim is time-consuming and frustrating. Moreover, arequestor being unhappy with a reported wait time of, say, 5 minutesbefore getting service has no way of knowing whether the second servicemight have any available appropriate experts and/or what THEIR waittimes might be.

The design of existing systems that provide remote, third-partyexpertise creates vendor lock-in, forcing an institution to offer topatients, say, vertically integrated services and technology that favorthe vendor's own resources, often at a higher-than-market-cost. Existingsystems do not allow requestors to select which remote experts, orthird-party organizations that provide expertise, are presented tousers. Instead, they are at the mercy of the technology vendor to selecta remote expert on their behalf and have limited options to overridethis decision to control cost and quality.

The present inventor has realized that yet another limitation ofexisting systems is that they offer limited options regarding howrequestors of expertise and experts are matched up. The most typicalscenario is a switchboard approach, where a person or set of rulesroutes the requestor to a remote expert within a vertically integratednetwork.

The expertise-provisioning system disclosed herein overcomes many of theforegoing problems in the art.

In particular, the disclosed system provides for open-ended provisioningof relationships between requestors and experts. Specifically, it doesnot assume a predefined relationship between the expertise-provisioningsystem and the pool of experts. It can dynamically broker multiplerelationships between requestors and experts (or sources of expertise)based on data-driven analytics, as well as allow management oforganizations that requestors work for (like hospitals) to controlprioritization of routing between experts or sources of expertise, bothinternally and externally.

In particular embodiments, the expertise-provisioning system is not theactual source of the expertise ultimately delivered to requestors.Rather, the expertise-provisioning system brokers relationships betweenrequestors of expertise and with sources of that requested expertise,which may include both first-party (e.g., in-house) and third-partysources. Specifically, the expertise-provisioning system can optimizethe provisioning of remote experts by choosing experts from among a) theinternal resources of the system client, meaning the organization orentity that has contracted with the proprietor of theexpertise-provisioning system for the services of theexpertise-provisioning system as described herein as well as b)third-party expertise vendors based on such criteria as cost, wait timesand specialized expertises, per “matching rules” that each system clientmay have specified.

To this end, the experts are, in particular embodiments, affiliated withso-called virtual call centers, the affiliates of which are notinterrelated by particular networking or technological infrastructureand may come onto the expertise-provisioning system from a wide varietyof devices. The affiliates of a particular virtual call center are,rather, typically experts whose work is governed by a particular entity(“expertise vendor”) that typically functions to do at least one of:on-board and/or manage and/or pay the experts in that virtual callcenter for their work. This means that the expertise-provisioning systeminteracts with the experts directly, rather than with an intervening“traditional call center.” Having the experts in virtual call centersenables the expertise-provisioning system to select experts on behalf ofrequestors based on the characteristics of their respective virtual callcenters, such as first-party versus third party and cost charged byvarious expertise vendors for the services of their experts. Theaffiliates of a particular virtual call center may also be in-houseexperts employed by the system client.

In particular embodiments, requestors can be availed of the neededexpertise based on multiple criteria rather than simply on the singlecriterion such as the languages to be interpreted in a given encounter.Such criteria can include the selection based on cost, wait time orcharacteristics about experts such as preferred gender.

The disclosed system allows users to request and receive specificexpertise from multiple disparate endpoints from within other (in thisexample) healthcare tools such as electronic education materials andcommunication and workflow tools, or simply via a standalone webpage ormobile application.

Particular embodiments allow for requests to be connected to multipleendpoints (both internal and third-party) simultaneously, and in a waythat is transparent to users. For example, a nurse needing help indealing with a psychotic patient who does not speak English may need thesimultaneous services of a behavioral health professional and a languageinterpreter.

DRAWINGS

FIG. 1 is a block diagram of an illustrative expertise-provisioningsystem embodying the principles of the present invention;

FIG. 2 is flowchart depicting an illustrative provisioning workflowperformed by the illustrative expertise-provisioning system of FIG. 1;

FIG. 3a through 3d are simplified screen presentations showing anillustrative sequence of screens that may be presented on the display ofa device of a requestor accessing the expertise-provisioning system ofFIG. 1;

FIGS. 4a through 4c are simplified screen presentations showing anillustrative sequence of screens that may be presented on the display ofa device of an expert available to provide expertise, e.g., languageinterpretation, via the expertise-provisioning system of FIG. 1;

FIG. 5 is a flowchart depicting an illustrative workflow by whichexperts available on the expertise-provisioning system are matched toexpertise requests;

FIG. 6 is flowchart depicting an illustrative resource availabilityworkflow performed by the illustrative provisioning system of FIG. 1;and

FIG. 7 is a flowchart depicting an illustrative workflow by whichcertain data may be supplied by a requestor as part of the requestingprocess.

DETAILED DESCRIPTION

FIG. 1 is a block diagram of an illustrative expertise-provisioningsystem embodying the principles of the present invention. In thedisclosed embodiment, the expertise-provisioning system comprises aninterrelated set of components that enables a user in need of expertise(“requestor”), e.g., language interpretation, to request that expertise;that automatically brokers relationships with sources of the requestedexpertise; and that enables the requestor to be put in electroniccommunication with a particular expert, illustratively by deliveringthat expertise in a communication session via one or more communicationmodalities such as audio, video, text. Also, the expertise-provisioningsystem of the disclosed embodiment can execute a secure transfer of datasuch as, in a healthcare context, patient demographics and medicalhistory transferred to a healthcare expert.

The system disclosed herein as implementing the principles of theinvention is feature-rich and, in particular, features real-timeecosystem awareness. Specifically, the particular system disclosedherein maintains real-time visibility of resources on network acrossmultiple virtual and real call centers. It provides both real-time andforecasted resource availability to requestors prior to making arequest, including estimated wait times. It has the ability to drivesupply to ecosystem based on forecast and real demand through proactivenotifications to potential suppliers of expertise. And it uses data andmetadata to automatically control routing of requests to expertsincluding, but not limited to: Connection quality, user ratings,patient-specific data, context-specific data, expert-specific data, andhistorical call data.

That being said, it is to be understood that the disclosed embodiment ismerely illustrative of a system embodying and implementing theprinciples of the invention as claimed herein. Particular otherembodiments implementing the broad inventive concept may be devised thathave more, fewer and/or different features than those that happen to beincorporated into the particular illustrative embodiment disclosedherein.

Architecture Overview

In overview, the expertise-provisioning system includes requestorend-user devices 10-1, 10-2 . . . 10-N via which requesting users(“requestors”) R-1, R-2 . . . R-N request expertise from theexpertise-provisioning system. The expertise-provisioning system alsoincludes remote expert end-user devices (“expert devices”) 40-1 . . .40-N each associated with a respective source of expertise,illustratively one the remote experts E-1 . . . E-M, who are availableto provide the requested expertise. Typical examples of the remoteexperts are foreign language interpreters, physicians, triage nurses,and health coaches.

For example, an English-speaking visiting nurse may be at the home of apatient who speaks Korean but little English and as a result thevisiting nurse is having trouble completing a health assessment for thepatient. The nurse is able to access the expertise-provisioning systemvia her smartphone to become connected to a Korean-speaking medicalinterpreter.

Remote experts E-1 . . . E-M are affiliated with a so-called virtualcall center VCC-1. There are actually Q virtual call centers VCC-1 . . .VCC-Q, each having a respective group of affiliated experts, with thepossibility that a particular expert may be affiliated with more thanone virtual call center. In brief, the experts of a particular virtualcall center are experts whose work is governed by a particular entity(“expertise vendor”) that typically functions to do at least one of:on-board, and/or manage and/or pay the experts in that virtual callcenter for their work. Examples of such expertise vendors are companiesemploying nurse triage and foreign language interpretation experts.Thus, the governance of the experts of many, if not most or all, of thevirtual call centers is separate from the governance of the experts ofthe other virtual call centers.

In addition, the experts of one or more of the virtual call centers maybe employed by, or affiliated with, the system client. The “systemclient” is an organization or entity that has contracted with theproprietor of the expertise-provisioning system for the services of theexpertise-provisioning system as described herein. For example, thesystem client may be a hospital and the experts of its virtual callcenter—referred to herein as a “first-party” call center—may be hospitalemployees or affiliates who have foreign language expertise and whosefull-time, part-time or just as-needed duties include serving as foreignlanguage interpreters. If desired, the services of the experts of thehospital or other system client can be made available to requestorsother than those affiliated with the system client. The system clientmay specify to the expertise-provisioning system that requestorsaffiliated with the system client should always given priority overother requestors.

An additional expertise resource can be a traditional third-party callcenter, such as third-party traditional call center 70 that communicateswith the expertise-provisioning system on behalf of the third-party callcenter's experts.

The expertise-provisioning system also includes provisioning engine 30.This is a highly-scalable application, hosted on a server 64, thatmaintains real-time awareness of the availability of remote experts orother resources by monitoring availability of such resources across allassociated call centers (both virtual and traditional) includingestimated wait times. Provisioning engine 30 engages in two-waycommunications with the requestor devices 10-1, 10-2 . . . 10-N toinform requestors about expertise availability and wait times; acceptsrequests for connection to experts; notifies appropriate experts ofrequests; and manages a process by which requestors becomeconnected—illustratively via a WebRTC connection—to experts who have“accepted” their request.

The expertise-provisioning system also includes request web application61—illustratively comprising an assembly of application programinterfaces (API)—hosted on server 60. (As is well known, an API mayactually comprise an assembly of interrelated APIs which, together,carry out some overall desired API functionality. For convenience, thisdescription uses the term API both to refer to such assemblies or anindividual API.) It is via request web application 61 that therequestors interact with provisioning engine 30. Theexpertise-provisioning system also includes expert web application62—also illustratively comprising an API—hosted on server 63. It is viaexpert web application 62 that the remote experts interact withprovisioning engine 30. As will be apparent to those skilled in the art,server 60 and/or server 63 may each actually be a group of serversproviding various specialized server functions. Moreover, servers 60 and63—shown as separate entities in FIG. 1—may actually be a single groupof servers hosting both of the web applications 61 and 62.

Architecture Detail

Requestor end-user devices 10-1, 10-2 . . . 10-N may be any type ofdevice by which requestors R-1, R-2 . . . R-N initiate a request for theexpertise-provisioning system to provide remote expertise, such aslanguage interpretation. Any given one of the devices 10-1, 10-2 . . .10-N may be, for example, a smartphone, tablet, laptop or desktopcomputer or any other suitable end-user device. In fact, any of thedevices 10-1, 10-2 . . . 10-N may be a “traditional” landline or mobiletelephone having only audio telephone capabilities. In such a case,requests for remote audio expertise can be initiated, for example, by arequestor dialing a specific telephone number for Spanish interpretationand the expertise-provisioning system—carrying out most of the stepsdescribed hereinbelow—ultimately provides an audio-only connection tothe remote expert or using a web interface as an audio-only call.

A requestor such as requestor R-1 may make a request to provisioningengine 30 via an expertise request tool 11 which is illustratively is amobile application (app). As an alternative, a requestor such asrequestor R-2 may make a request to provisioning engine 30 throughrequest web application 61 via a web interface 12 on a standard webbrowser. As another alternative, as illustrated for requestor R-N, asimilar API expertise request tool may be embedded in third-partysoftware 13 such as educational software or a third-party webapplication or web page. As an example, a patient may go home after kneesurgery and receives an interactive education module about hisrehabilitation program. That patient has questions about how to performcertain exercises correctly and presses an “I have questions” button inthe education module. This causes an expertise request notification tobe transmitted to experts in one or more virtual call centers, as hasbeen previously specified by the healthcare provider (“system client”)that is managing the patient's rehabilitation program, based on certainexpert-matching rules discussed below. One of the virtual call centersmay be a first-party virtual call center whose affiliated experts arephysical therapists employed by the healthcare provider itself. Anotherof the virtual call centers may be operated by a third-party expertisevendor that the healthcare system has authorized to perform work on itsbehalf.

Request web application 61 collects information from requestors that isused to help the expertise-provisioning system automatically identifyone or more appropriate resources on the network, such as one of expertsE-1 . . . E-M that could provide the requested expertise. Thisinformation may be collected through screen inputs and/or from adatabase, accessible to request web application 61, in which is storedinformation about that requestor based, for example, on previousexpertise request communication sessions with that requestor. Theinformation in question may include, for example, requestor role (e.g.,job title) and context (e.g., identity of the requestor's employer orphysical facility or identity of the third-party software or web contentthrough which the requestor initiated the request.) Other collected orpreviously-stored information may include requestor-specific data suchas demographic information, and the requested expertise, e.g., Spanishinterpretation. This information-collecting may happen, for example, viaexpertise request tool 11 or web interface 12 displayed on therequestor's web browser, depending on how the requestor is accessing theexpertise-provisioning system. Or in certain cases, where the requestorweb application is embedded in a third-party web application or othersoftware, some or all of the foregoing information could be passeddirectly to request web application 61 from within the web applicationor other software without requestor input.

Any given one of the expert devices 40-1 . . . 40-M may be, for example,any of the types of devices mentioned above in connection with devices10-1, 10-2 . . . 10-N. For example, the device 40-1 of remote expert E-1is illustratively a smartphone. Instantiated in the smartphone is aremote expert interface 41 which, in this example, is a mobileapplication (app) via which expert E-1 accesses expert web application62. It is via interactions with expert web application 62 that remoteexpert E-1, through remote expert interface 41, signs into theexpertise-provisioning system and sets her status to “available,”thereby enabling provisioning engine 30 to be aware in real time of heravailability to take requests, e.g., for language interpretation, and toroute requests to her. Alternatively, the expert's identity can beautomatically reported to the expertise-provisioning system when theexpert signs onto the expertise-provisioning system via third-partysoftware in which expert web application 62 is embedded.

As an alternative to accessing expert web application 62 via expert webinterface 41, a remote expert, such as remote expert E-M, may accessexpert web application 62 via a web interface 43 displayed by on astandard web browser.

Since an expert will have previously been administered into theexpertise-provisioning system, relevant information about the expertthat will be used by provisioning engine 30 to identify possible expertsto fulfill a given request can be looked up from an database that ismaintained either by provisioning engine 30 or the expertise vendor withwhich the expert is question is affiliated, such as a foreign languageinterpretation provider. This information may include the remoteexpert's expertise(s) (e.g., languages that the expert can be aninterpreter for). It may include also an identification of which of theone or more virtual call centers VCC-1 . . . VCC-Q the expert isaffiliated with, and/or expert-specific data such as demographicinformation (e.g., gender).

Experts may be affiliated with one or more virtual call centers. When anexpert signs on to the expertise-provisioning system, she may designateher availability to take requests in her capacity as an affiliate forany one or more of the virtual call centers that she is affiliated with.Consider this example: The expert is a Spanish interpreter affiliatedwith two virtual call centers A and B. Virtual call center A chargesrequestors less per minute than virtual call center B and also pays itsInterpreters less. At times of day when the expert has learned throughexperience that requests for interpretation tend to be more infrequentthan average, the expert may designate her availability to take requestsin her capacity as an affiliate for both virtual call centers A and Bbecause even though virtual call center A will pay her less, somerequests will be based on expert-matching rules that, for one reason oranother, exclude the higher-paying virtual call center B and she wouldrather earn something than sit idle. On the other hand, at times of daywhen the expert has learned through experience that requests forinterpretation tend to be more frequent than average, the expert maydesignate her availability to take requests only in her capacity as anaffiliate for the higher-paying virtual call center B because she hasfound that she will receive enough requests solely as an affiliate of avirtual call center B expert to keep her busy.

It may be appreciated from the foregoing that the expertise-provisioningsystem proprietor may well have only a technological relationship, andnot any financial relationship, with the experts or the expertisevendor. Specifically, in at least certain embodiments, it is envisionedthat the expertise-provisioning system proprietor's businessrelationship will be with the system clients, e.g., hospitals, wherebyrequestors affiliated with the system client are provided with accessthe expertise-provisioning system in exchange for financialconsideration from the system client to the proprietor of theexpertise-provisioning system. A hospital will have previously arrangedwith, e.g., contracted with, for example, an expertise vendor that is aninterpretation company who employs interpreters—various ones of theexperts E-1 . . . E-M. In exchange for financial consideration from thesystem client to the expertise vendor, the latter's experts will beincluded among the experts that the expertise-provisioning system mayconnect to in order to provide interpretation services to requestors whoa) are healthcare providers (doctors, nurses, aides, etc.) who workwithin the hospital and/or b) are the hospital's patients and/or c) areother affiliates of the system client who have been authorized by thesystem client to access the expertise-provisioning system. The patientsmight be enabled to access the expertise-provisioning system via abedside tablet supplied by the hospital or via their own personal devicewhich they might use either in the hospital or at home after discharge.The hospital has decided that it is advantageous to access the expertisevendor's interpreters via the expertise-provisioning system because theexpertise-provisioning system provides many advantages, as will beappreciated from this description, over the traditionaldirect-access-to-the-interpretation-company model. The expertisevendor's experts will thereupon gain access to theexpertise-provisioning system by being provided with a) appropriatecredentials and security tokens (e.g., user names and passwords) and b)an instantiation of remote expert interface 41, e.g., via download, orbrowser access to expert web application 62.

In another scenario, an expertise vendor may have already affiliated itsexperts with the expertise-provisioning system and it proposes to new orexisting clients, e.g., hospitals, that the clients obtain access to theexpertise vendor's experts via the expertise-provisioning system.

As noted above, an additional expertise resource is third-party callcenter 70. Third-party call center 70 is a traditional call centerwherein its experts are logged into the traditional call center's owncall center platform 71 managed by its own administrative tools 711.Unlike experts E-1 . . . E-M of virtual call center VCC-1, for example,the experts 75 affiliated with call center platform 70 do not havedirect access to expert web application 62 and, as such, experts 75 arenot “seen” by the expertise-provisioning system. Rather the availabilityof resources of traditional call center 70 is made known to provisioningengine 30 via an API layer 713 instantiated on call center platform 71.Requests for expertise communicated to traditional call center 70 fromprovisioning engine 30 are matched to remote experts affiliated withtraditional call center 70 by way of communications between provisioningengine 30 and the call center's conventional outward-facing provisioningAPI 712, as intermediated by API layer 713. Provisioning API 712 is theprogramming by which traditional call center 70 accepts requests forexpertise in the traditional way in which requests dial into the callcenter on the telephone or access it via a web page. Thus unlike in thecase of the virtual call centers as discussed below, the provisioningsystem of this disclosed embodiment interacts with the call centerplatform 71 rather than with the experts 75 directly.

Software Platform Components

FIG. 1 further shows the various components of various software elementsof system, collectively referred to as the expertise-provisioningplatform. What follows is a brief description of some of thefunctionalities of those software elements. Those skilled in the artwill readily be able to determine what other functionalities might bedesirable for those software elements to implement, as well as whatother software elements might be included in the overallexpertise-provisioning system platform, in order to carry out thevarious functionalities disclosed herein for the overallexpertise-provisioning system.

Request web application 61 includes data collection service 611,provisioning service 612 and security layer 613.

Data collection service 611 collects information about the requestor, asdetailed above. (Although not shown in the FIG., some of the datacollection may be performed by expertise-request tool 11.) Datacollection service 611 also collects various pieces of administrativeinformation about the session that can be used by theexpertise-provisioning system for, for example, administration andanalytics, this including such pieces of administrative information asduration of the session, wait time to connect, post-session ratings fromthe requestor etc.

Provisioning service 612 receives information from resource availabilityservice 32 of provisioning engine 30 as to the availability andestimated wait time of remote experts, as described in further in detailhereinbelow. That information is thereupon provided to requestors'devices. Provisioning service 612 also communicates a requestor'srequest to master provisioning service 31 of provisioning engine 30. Italso receives routing information from the master provisioning serviceidentifying the route to connect to the identified expert using asession description protocol as known in the art, to ultimatelyestablish a peer-to-peer connection—or alternatively, a relay servertype connection—using WebRTC, for example.

Security layer 613 manages the requestors' credentials and identities aswell as exchanges security tokens with security and tokening component35.

Expert web application 62, includes security layer 621, provisioningservice 622 logging & auditing service 623 and notification service 624.

Security layer 621 performs a similar function to security layer 613 butwith respect to the relevant expert rather than the requestor.Provisioning service 622 makes notifications to matching remote expertsabout pending requests for which they have been identified as potentialsuppliers of the requested expertise and receives an acceptance of therequest from whichever expert (if any) signaled an acceptance by, forexample, pressing an appropriate button presented by remote expertinterface 41 or in the web interface 43 presented on the expert's webbrowser. (Once an expert has accepted a request, it disappears from thedevices of all the other experts who had received it.)

Provisioning service 622, similar to provisioning service 612 in requestweb application 61, receives connection-related information from masterprovisioning service 31 so that a connection between the requestor andexpert can ultimately be established.

Logging & auditing service 623 maintains an awareness of expertavailability and status (e.g., ““available,” “unavailable” and “in acall”) and communicates that information to resource availabilityservice 32.

Notification service 624 queues and manages all notifications for allusers (experts for instance) and handles the delivery across modalities.For example, one expert might be notified of incoming requests directlyon the expert's browser as well as via a text message. Notificationservice 624 can also function proactively in connection with masterprovisioning service 31 to send notifications to not-available expertsby, for example, email, automated phone call or SMS in a case where theexpertise-provisioning system recognizes that there are currently notenough experts to fulfill the current demand within some time-framelimit or that the wait time trend is upward, and it is expected thatthere will soon not be enough experts to fulfill future demand. Expertsreceiving such notifications are thus prompted to make themselvesavailable given that there is or is expected to be an increased demandfor their services.

Provisioning engine 30 includes, as already mentioned, masterprovisioning service 31, resource availability service 32 and securityand tokening 35, which function as described above. Provisioning engine30 also includes analytics layer 33, expert-matching rules 34 andadministrative tools 36. Administrative tools 36 perform conventionaltypes of functions for systems of this type, as will be appreciated bythose skilled in the art. Analytics layer 33 determines wait times basedon the workflow shown in the flowchart of FIG. 6, as described below.Analytics layer 33 may also produce other data-driven metrics requiredby master provisioning service 31 to identify appropriate experts tofulfill the request for a given expertise, e.g., Spanish interpretation.In particular, analytics layer 33 executes algorithms that take intoaccount certain expert-matching rules 34 that have been specified by thesystem client (e.g., a hospital). Thus expert-matching rules 34comprises a table or other data structure defining the expert-matchingrules (if any) defined by each system client.

In particular, the expert-matching rules may involve such criteria as a)an identification of the expertise vendors that the system client hascontracted with for the vendors' services (“authorized expertisevendors”); b) professional certifications of the available experts(e.g., “certified medical interpreter”), c) the cost per minute chargedby the available experts' expertise vendor(s), and d) the current waittimes for a requestor to be connected to an expert, to give just someexamples. Another possible expert-matching rule may be that an expertsuch as a physician has a particular professional licensure. Inparticular, a state, e.g., a state of the United States, may requirethat if a person within that state is receiving medical advice from aphysician during an electronic communication session, the physician mustbe authorized to practice medicine in the requestor's state—by beinglicensed by either that state or by another state through a reciprocityagreement. Thus the matching rule may be that if the requestor's statehas such a requirement, a notification of a request for the expertise ofa physician will be sent only to physicians who are authorized topractice medicine in the requestor's state, as would be determined fromthe profile of that physician maintained by the expertise-provisioningsystem, as described below. It is possible that some criteria forselecting experts can be incorporated either into matching rules orindividual requestors may be given the opportunity to specify thosecriteria as metadata, as described below.

Also shown in FIG. 1 is a database DB accessible by provisioning engine30 to store and retrieve various kinds of information including profilesof the various experts, configuration settings for system clients andcall centers, credentials and personal details for various system usersand other kinds of information that will be recognized by those skilledin the art as useful for implementing such a system. In particularembodiments, passwords and personal details may be encrypted anddistributed into multiple disconnected datasets for security purposes,as is well known in the art. API 131 of third-party software 13 is acomponent of the expertise-provisioning system platform that is embeddedinto third-party software, such as educational software. A requestoraccesses the services of the expertise-provisioning system (which inthis case would more likely be, for example, the services of a subjectmatter expert or a healthcare expert, rather than a languageinterpreter) via a button displayed by API 131 within the third-partysoftware. API 131 illustratively provides a functionality similar tothat of requestor web application 61 and, as such, communicates directlywith provisioning engine 30.

Workflows

FIGS. 2-7 are flowcharts of workflows, and associated simplified screenviews (hereafter “screens”), carried out within theexpertise-provisioning system in the course of theexpertise-provisioning system providing the various functionalitiesdescribed herein. The functionalities shown in the flowcharts relatingto interactions between the requestor devices 10-1, 10-2 . . . 10-N andrequest web application 61 may typically be carried out principally byrequest web application 61, with only a relatively smaller portion ofthe functionality being carried out by expertise request tool 11 or in aweb interface 12 displayed on a requestor's web browser. Similarly, thefunctionalities shown in the flowcharts relating to interactions betweenthe expert devices 40-1 . . . 40-N and expert web application 62 maytypically be carried out principally by the request web application 62,with only a relatively smaller portion of the functionality beingcarried out by expert interface 41 or in the web interface 43 presentedon an expert's web browser by programming, e.g., JavaScript, embedded inthe web interface. Those skilled in the art will appreciate that theextent of the division of functionalities and how they are implementedis a matter of design choice for the system designer and is well withinthe skills of those skilled in the art.

FIG. 2 is a flowchart depicting an illustrative provisioning workflowperformed by the expertise-provisioning system of FIG. 1 in order toconnect a requestor to an expert.

A requestor (e.g., healthcare provider) accesses the system (at 261),by, for example, opening expertise request tool 11 or accessing awebsite maintained by the expertise-provisioning system. In thisembodiment, the expertise-provisioning system proprietor assigns aunique URL to each system client. Requestors accessing theexpertise-provisioning system via their web browsers do so by way ofthat particular URL, so that the expertise-provisioning systemautomatically becomes aware of the identity of the system client withwhich the requestor is associated. In the case of requestors accessingthe expertise-provisioning system via expertise-request tool 11, thatURL or other client-identifier is automatically embedded in the tool sothat, again, the expertise-provisioning system knows which system clientthe requestor is associated with. In the case of third-party software13, pressing a button displayed within third-party software by API 131embedded therein identifies to provisioning engine 30 what theparticular educational, or other third-party, software actually is, suchas “Managing Your Diabetes” distributed by the (fictitious) company XYZMedical Solutions. It can also include a data collection aspect so as toprovide contextual awareness that may inform provisioning engine 30 ofthe particular section of the educational material is being viewed bythe requestor and thus may provide additional data useful in identifyingappropriate matching experts.

Given that the identity of the system client (e.g., hospital) is known,all the system needs to validate the requestor is that the requestorsupplies a correct security token, e.g., password or other credentialsthat identify the requestor as being affiliated with that particularsystem client and authorized to access the expertise-provisioning systemby that system client. The security token may be already known withinthe requestor's device and thus automatically transmitted toprovisioning engine 30 or else may be prompted for. The validation iscommunicated by provisioning engine 30 back to request web application61 which thereupon collects various call- and requestor-related data andmetadata in any of the manners mentioned above (264).

After the requestor's security token has been validated, the requestoris illustratively presented with a screen such as shown in FIG. 3a ,wherein the requestor is prompted to provide certain information aboutthe session being requested. In this example, that information includesthe hospital department (“Maternity”) into which a patient for whominterpretation is needed has been admitted; the patient'shospital-assigned ID (“123456”) and the patient's gender (“Female”). Thevarious information fields may be populated by way of pull-down lists,as depicted, and/or free-form entry. In a subsequent screen (not shown)the requestor could be prompted for other metadata such as therequestor's preferred gender of the expert, a second desired expertisefor the expert, or a particular professional certification. Suchmetadata can be used by the expertise-provisioning system whenidentifying appropriate experts to notify of the request, as describedbelow.

The requestor is thereupon presented with a screen such as shown in FIG.3b from which the requestor can select the kind of remote expert neededand whether a video or audio (only) session, or call, is desired. Threechoices of expertise are presented: Spanish Interpreter, FrenchInterpreter and Physician Consult. Those particular three choices can bechosen, for example, by the system based on past history of requestsfrom the hospital in question, or from the particular requestor, or fromthe particular patient. One or more choices, such as Physician Consult,may always be presented by default. If the requestor requires anexpertise not displayed, she may select an “Other Experts” button thatwill display further choices of languages and/or other expertises and/ora generic “help” button. For example, a patient suffering from apulmonary disease who has recently been discharged from the hospital maybe having trouble breathing. That patient may press the “help” buttonand thereupon be connected to a triage nurse. In a similar vein, arequestor might press a “speak to a health educator” button.

Also shown on the screen of FIG. 3b are respective estimated times thatthe requestor will have to wait before being connected with an experthaving the desired expertise via either video or audio. These estimateswill have been provided by analytics layer 33 of provisioning engine 30in accordance with the workflow shown in the flowchart of FIG. 6, anddiscussed hereinbelow.

At this point, provisioning engine 30 (at 270) receives the requestor'sselection of remote expertise as well as an indication from therequestor as to the desired type of communication is desired with theexpert, such as audio, video or text message. In this example, therequestor has selected a Spanish interpreter video call.

Depending on the nature of the expertise requested, the requestor mightbe prompted on a subsequent screen (not shown) for additional metadatathat may help the provisioning engine to identify an appropriate set ofexperts to be notified of the request and/or to provide the matchingexpert with information to assist the requestor. This is described infurther detail hereinbelow in connection with the workflow of FIG. 7

FIG. 3b is but one example of how requestors might be presented withoptions for the upcoming electronic communication session. For example,instead or, or in additional to, being shown estimated wait times fordifferent types of communication, such as audio or video, the requestermight be shown options related to other criteria. For example, arequestor who has specified a preferred gender for the expert might beshown estimated wait times for both male and female experts

In the meantime, various experts who have previously logged into thesystem are ready to accept requests by way direct communication with theexpertise-provisioning system, that is without any interveningexpertise-management entity such as a third-party call center platform.FIG. 4a shows a screen illustratively displayed to a particular expertwho has logged into the system via remote expert interface 41 or webinterface 43. and is available to receive the requestor's request. Inthis embodiment, the screen includes a video preview of a “head shot” ofthe expert—taken by a video camera associated with the expert's expertdevice—so that the expert can see the video of him/herself that will bedisplayed to a requestor once a session has been set up. As also shown,the expert has already selected an “Available” button displayed in thescreen, thereby indicating that the expert is, in fact, presentlyavailable to accept and/or fulfill requests for that expert's particularexpertise(s). (An “Unavailable” button is also displayed enabling theexpert to indicate at some subsequent time that the expert does not wantto receive requests.)

After the requestor has made a selection from the screen of FIG. 3b (orsome other screen that was accessed from the screen of FIG. 3b asdiscussed above) a screen such as FIG. 3c is presented to the requestorconfirming the requestor's request and indicating that the system iswaiting for a remote expert to accept the request.

At substantially the same time, expertise-provisioning system hastransmitted (271) a request notification to the expert devices of allexperts who have indicated that they are “available” and who match thepending request, i.e. have been identified as potential suppliers of therequested expertise—in this case Spanish interpreters with videocapability who are affiliated with particular virtual call centersand/or third-party call centers that the system client has madearrangements with, as described above. FIG. 4b shows an illustrative“New Request” screen that is thereupon displayed to all such experts.

A matching expert who wishes to accept the request will thereupon acceptthe request (273) by, for example, clicking on an “accept” buttondisplayed in the screen of FIG. 4b . The acceptance is received atprovisioning engine 30, which thereupon identifies the remote expert inquestion from information contained in the received communication (274)and at the same time returns the expert's screen to that of FIG. 4 a.

It may be the case that no experts with matching expertise are logged inand have indicated that they are “available.” If desired in certainembodiments, such an expert might be prompted by an SMS message, email,automated phone call (IVR), or any other desired mechanism to log in soas to be able to be connected to the requestor.

Returning for a moment to step 273, it may be that no remote expertaccepted the request. It may be the case that there are no other expertsavailable. That is, all of the available experts that theexpertise-provisioning system has been administered to call upon on werealready presented with the request at 271. In that case, the workflowwaits at 273 for a matching expert to accept. Alternatively, theworkflow returns to 270 responsive to the requestor, seeing that noexpert is immediately available, modifying the request (at 270), such asby changing the request from video to audio.

On the other hand, there may be other experts that theexpertise-provisioning system has been administered to send a requestnotification to, per the system client's expert-matching rule(s) 34. Forexample, the expert-matching rule may be to send request notificationsin the first instance only to in-house experts (in the first-partyvirtual call center) unless the estimated wait time to do so exceeds await time specified in the expert-matching rule(s). If for any reason,none of the original matching group accept the request within the timethreshold, then the experts of a third-party virtual call center withwhom the system client has contracted should thereupon be sent anotification request. In that case the workflow again presents therequest (at 271) but to the matching experts of that particularthird-party virtual call center. This workflow can repeat any number oftimes until a remote expert accepts the request at 273 or the requestorabandons the request, e.g., hits a “cancel” button. Alternatively, thesystem may use predictive analytics to estimate the wait time for amatching first party expert, and proactively route the request to athird-party virtual call center because the first party experts areexpected to exceed the time threshold.

Once a specific remote expert has been identified at 274, provisioningengine 30 sets a flag or otherwise denotes (276) that that particularremote expert is “in a call” so that the expertise-provisioning systemwill regard that remote expert as being unavailable when carrying outsubsequent expert-matchings in response to subsequent requests.

At this point, the requestor is enabled to be in electroniccommunication with the accepting expert. To this end, the remoteexpertise session is illustratively connected peer-to-peer using aservice like WebRTC (279) as previously described. In certain cases,typically at the request of customers with specific networkingrequirements, communication may involve a secure relay server as asupplement to peer-to-peer interactions. FIGS. 3d and 4c show thescreens illustratively presented to the requestor and the expert,respectively, at this time. The requestor (expert) is presented with thevideo being generated by the expert's (requestor's) device's camerawhich will be a head shot of the expert (requestor) if s/he is sittingin front of the camera. The requestor and the expert each see an insetvideo of themselves. The expert's screen illustratively includes alegend identifying the requestor—illustratively the requestor'sorganization (“Rose Tree Hospital”) The video session typically includesaudio as well but a two-way chat window is also available for therequestor and expert to communicate by text. Selecting an “Add AnotherExpert” button presented to both the requestor and the expert alloweither of them to add another expert to the session, which is readilyaccomplished the service by which the remote expertise session isconnected, such as the WebRTC protocol. For example, a requestor whospeaks English as a second language may have thought that she was fluentenough to conduct a session with an English-speaking physician or otherexpert, only to discover that the services of a language interpreter areneeded. By selecting the “add another expert” button, the requestor ofthis example, would be led to a screen such as that of FIG. 3b —perhapsin a window overlaid or next to a window in which thealready-in-progress session is displayed—with the added-in expertultimately appearing in that window. Selecting an “End Call” buttonpresented to both the requestor and the expert allow either of them toend the session.

Once the session concludes (at 283), the expertise-provisioning systemperforms automatic audits (at 287) by, for example, collecting data on,connection duration, wait time, party that terminated the session, etc.Also collected are user satisfaction ratings. Both the requestor and theexpert may be asked to rate the quality of the connection, level ofsatisfaction with wait time, etc. The requestor may also be asked torate the quality of service provided by the expert. These are logged ina database (285) and are used for future provisioning and administrativereporting. Finally, the status of expert in question is reset to“available” (289).

The workflow of FIG. 2 applies to the connecting of requestors toexperts wherein the experts are either in virtual call centers or are“behind” a traditional call center such as call center 70. The virtualcall center scenario involves conventional types of processing andcommunications among the various disclosed software elements of theoverall expertise-system software platform in implementing theprinciples of the present invention. As to the traditional call centerscenario, a further word about an illustrative implementation may behelpful. In particular, assume that platform 71 is one that employs thecommunications protocol referred to as SIP (Session InitiationProtocol). Using that protocol, platform 71 can indicate to provisioningengine 30 the availability of ones of its remote experts 75. Onceprovisioning engine 30 has determined that the traditional call center70 meets the request—and assuming that the requestor has requested anaudio connection, provisioning engine 30 generates an SIP call to thecall center, the call containing per the SIP protocol data such as thelanguage requested. If an appropriate one of the experts 75 isidentified by platform 71 as being able to fulfill the request, platform71 completes an audio connection between the identified one of experts75 and provisioning engine 30. The latter then connects audio from theSIP-based system to web audio (such as WebRTC) and vice versa so thatendpoints from traditional telephones and web-enabled endpoints caninteract with each other in furtherance of the remote expertisecommunication session. Further, the system broadcasts information aboutthe request via SIP header or similar mechanism to inform thetraditional call center of requested expertise and other information.

FIG. 5 is a flowchart of the workflow by which provisioning engine 30uses the request-specific information and, possibly, one or moreexpert-matching rules specified by the expertise-provisioning systemclient on behalf of its authorized requestors, to identify matchingexperts. At the center of the workflow is the creation of a requestprofile 511. The request profile is matched against available remoteexpert(s), the matching remote experts are notified of the request andultimately one remote expert accepts the request.

In particular, the request profile is a collection of data gathered froma number of sources. That data illustratively includes one or more of:data contained in the expertise request itself (506), including type ofexpertise requested or urgency of the request; metadata about, forexample, the patient and/or the requestor that was collected (501) byexpertise request tool 11 or web interface 12 (FIG. 1), such metadataincluding requestor's role in the organization or demographicinformation about the patient; similar metadata that may have beencollected (503) by a third-party web application or software, asdescribed hereinabove; and a database DB (also shown in FIG. 1)containing previously collected data about, for example, the patientand/or the requestor, as well as other information including thatmentioned hereinabove in connection with the description of FIG. 1.

One or more remote expert groups are now identified (514) in accordancewith predefined criteria. Illustratively two remote expert groups areidentified—a first tier remote expert group and a second tier remoteexpert group—although any number of tiers is possible. The experts ofall the groups must meet the criteria specified by the request and itsmetadata, including the expertise requested, virtual call center and/orthird-party call center affiliations, price constraints, etc. Thedifference between the experts in the individual tiers is that the firsttier remote expert group are individual remote experts and/orthird-party call centers who not only meet request criteria, but alsofulfill certain of the matching rules 34, specified by the system client(e.g. hospital) on behalf of its authorized requestors which will causethose experts to be the first notified of the request, and thus thefirst who are given a chance to accept it, ahead of other experts. Thoseexperts are put into the first tier remote expert group and all theother matching experts will be put into the second tier remote expertgroup. For example, a matching rule may be that the expert provisioningsystem should notify experts within the system client's own “firstparty” virtual call center—i.e. experts who are employed by the systemclient itself—unless the estimated wait time exceeds some predeterminedtime. Another possible matching rule might be that the expertprovisioning system should notify lowest-cost experts unless theestimated wait time exceeds some predetermined time.

Looking then at the flowchart, it is seen that if the actual expectedwait time is within the matching-rule-specified time limit, (519) thenonly the first tier remote expert group is notified of the request(520). A first-tier expert may thereupon accept the request (524) withinthe matching-rule-specified time limit. On the other hand, once theactual wait time exceeds the matching-rule-specified time limit(523)—that is, the actual wait time turned out to exceed that which hadbeen estimated with any remote expert from the first tier havingaccepted the request—then the second tier experts are notified and,ultimately, an expert from one or the other of the tier will accept therequest unless, at some point, the requestor does not want to wait anylonger and cancels the request and possibly initiates a new requeste.g., one with a different media type. See the NO (OPTIONAL) branch outof step 273 in FIG. 2.

Returning to 519, it may be that the expected wait time exceeds thematching-rule-specified time limit, in which case the experts of boththe first and second tiers will be notified (520 and 521) immediatelyrather than seriatim.

More generally, matching rules 34 can be thought of as a set of lineardecision points. For example, first prioritize on wait times at allcosts, then prioritize to the least expensive resources available, thenfind an expert of the gender preferred by requester. So going throughsuch a decision process, one might group remote experts into any numberof tiers, as noted above, rather than only two tiers. For example, onemight group remote experts who match perfectly into the first tier,meaning that all the applicable matching rules are met; wait 30 secondsfor one of them to respond before notifying the second tier, in whichthe experts match the matching rules to a large extent; then waitanother 30 seconds for an expert from either the first or second tiersbefore notifying a third tier whose experts match the matching rules toat least some extent; then wait another 30 seconds for an expert fromany of the first, second or tiers before notifying a fourth tier whoseexperts do not match any of the matching rules while still at leastmeeting the criteria specified by the request and its metadata,

FIG. 6 is flowchart depicting an illustrative resource availabilityworkflow performed by the illustrative provisioning system of FIG. 1and, in particular, resource availability service 32 (FIG. 1). Inoverview, in order to give a wait time estimate to a customer extremelyquickly, the system first checks to see if it has estimated a similarwait time for another requestor within some preselected time period and,of so, it uses that prior estimate as the estimate presented to thepresent requestor. This saves processing cycles and database queries,speeding up the system. If such a prior estimate is not available, thesystem makes a new estimate.

In particular, provisioning service 612 requests (661) resourceavailability service 32 to provide information as to the wait time for aremote expert and communication medium (e.g., video or audio) in orderto be able to display same on the screen of FIG. 3b , for example.Metadata about that request is collected (662), the metadata including,for example, the expertise for which availability is are needed and anidentification of the authorized call centers for this requestor. (Notefrom FIG. 3b , for example, that typically a number of wait times willhave to be requested and thus the workflow of FIG. 6 will be executedfor each of them.

Analytics layer 33 maintains a cache 671 of recently estimated waittimes. If a cached wait time for the request at hand is available (664),and if the cached information is not too old (666) based on a predefinedtime window, then the cached estimate is delivered to provisioningservice 612 for use in presenting wait times to the requestor (see FIG.3b ).

On the other hand, if there is no match in the cache (664) or the cacheinformation is too old (666), then a refreshed wait time is requested(683) from analytics layer 33. Resource availability service 32 keepstrack in real time of the availability (679) of each of the experts ineach of the virtual call centers and collects that information (674).Since the expertise provisioning system does not have direct access tothe experts of the third-party call centers, it must rely on wait timeinformation supplied by the third party call centers via API (681) andthat information is collected (676) from all the third-party callcenters. In embodiments where the proprietor of the expertiseprovisioning system is concerned about the accuracy of wait timesreported by one or more of the third-party call centers, analytics layer33 may adjust (673) the wait time reported by a third-party call centerbased on observed discrepancies between wait times reported by thatthird-party call center in the past and actual wait times thateventuated. Analytics layer 33 uses a) the (possibly adjusted) waittimes reported by the third-party call centers, b) the virtual callcenter experts' availabilities collected by the resource availabilityservice and c) historical wait time data, to compute (678) a wait timeestimate for the request. The estimate is cached in 671 and supplied toresource availability service 32 (683) which, in turn, delivers theestimate to master provisioning service 31 (668).

As noted above, information other than the nature of the expertise andthe preferred communication medium (e.g., video/audio) may be collectedfrom the requestor prior to the request being sent to available expertsin order to help the provisioning engine identifying an appropriate setof available experts and/or to provide the matching expert withinformation to assist the requestor. The collection of such metadata ispart of step 264 (FIG. 2) and it is envisioned that screen(s) thatcollect such data (not shown in the FIGS.) would be presented to therequestor after the screen of FIG. 3b and before the screen of FIG. 3 c.

For example, if the request is for a physician contact, therequestor—who might be, for example, a healthcare provider at thebedside of patient—might be prompted to input particular metadata suchas the patient's blood pressure before the system moves ahead to notifypotential experts of the request. As another example, if a request is tobe made to a dietary planning expert, a data collection field might askif the requestor is vegetarian. Or if the request is to be made to abehavioral health specialist, the requestor might be asked to answer aset of basic questions to see if a suicide intervention is needed, inwhich case the request notification might be limited to experts withsuicide intervention training. Another possibility might be for thesystem to prompt the requestor on such a subsequent screen to upload adocument stored on, or accessible to, the requestor's device such as anelectrocardiogram.

FIG. 7 shows an illustrative workflow by which such metadata collectioncan be implemented. The request having been made (701) it is determined(704) whether additional data needs to be gathered based on criteriasuch as those mentioned above. If not, the request is sent (707) to theappropriate experts as described hereinabove. If additional data doesneed to be gathered, then appropriate screens are presented to therequester to collect that data (706). The data is stored in a securedata store 714 and then the request is sent (707). Once a remote expertaccepts the request (709), the data is delivered (711) to the expertthrough a secure web interface and displayed to the expert in anydesired manner, such as side-by-side with a window containing thecommunication session or under a separate tab. The data is also placed(716) into a reporting data repository for that session for viewing byauthorized administrative personnel at customers.

The session then begins (718) and after it ends (719) the remote experthas the option to enter additional data into data store 714 via a screen(not shown) presented to the expert after the session has ended.

Other embodiments might provide for the interchange of data between therequestor and the expert while the session is in progress.

CONCLUSION

The foregoing merely Illustrates the principles of the invention.

For example, at its core, the expertise-provisioning system is anexchange model for brokering relationships between those seeking remoteexpertise, and qualified remote experts. These include languageinterpretation that may or may not be invoked in a healthcare setting;healthcare scenarios that may or may involve language interpretationincluding remote health coaching, dietary guidance, post-acuterehabilitation, nurse triage and behavioral health counseling; and lawenforcement scenarios involving remote forensic interviews when specialexpertise is required, such as when dealing with children andcognitively impaired witnesses. More generally, the disclosedexpertise-provisioning system can be used in any realm where it isdesired to provide a user with remote access to a live individual withspecialized expertise.

In addition, the embodiment assumes a particular source language, e.g.,English, is the spoken language of requestors, so that a request for aSpanish language expert, for example, is fulfilled by identifyingmatching experts who can interpret between Spanish and English. In otherembodiments, however, a requestor may be able to specify her sourcelanguage, e.g., German, so that the request for a Spanish languageexpert will be fulfilled by identifying an expert who can interpretbetween Spanish and German.

The specific hardware and software structures and arrangements and theirparticular functionalities, workflows and modes of operation that aredescribed herein merely illustrate one of a large number of possiblealternative structures and arrangements that those skilled in the artwill be able to devise in order to implement the principles of thepresent invention.

It will thus be appreciated that those skilled in the art will be ableto devise numerous arrangements which, although not explicitly shown ordescribed herein, embody the principles of the present invention and arethus within its spirit and scope.

1. A method for use in a expertise-provisioning system, the methodcomprising enabling a requestor who has accessed theexpertise-provisioning system to be put in electronic communication withan expert who has a particular expertise specified by the requestor andwho also meets at least one other criterion specified by, or specifiedon behalf of, the requestor.
 2. The method of claim 1 wherein the atleast one other criterion is that the expert is to have a secondparticular expertise.
 3. The method of claim 1 wherein the at least oneother criterion is that the expert is to have a particular professionalcertification or licensure.
 4. The method of claim 1 wherein the atleast one other criterion is that the expert is to have a particularpersonal characteristic.
 5. The method of claim 4 wherein the particularpersonal characteristic is the gender of the expert.
 6. The method ofclaim 1 wherein the requestor is authorized to access theexpertise-provisioning system by a particular system client of theexpertise-provisioning system, and wherein the at least one othercriterion is a criterion that was previously specified to theexpertise-provisioning system by the system client.
 7. The method ofclaim 6 wherein the expertise-provisioning system enables the requestorto access the expertise-provisioning system in response to the requestorpresenting to the expertise-provisioning system credentials identifyingthe requestor as being affiliated with the particular system client. 8.A method for use in a expertise-provisioning system, the methodcomprising receiving a request made by a requestor who has accessed thesystem, to be in electronic communication with an expert having aparticular expertise, and responding to the request by enabling therequestor to communicate with a particular expert from among a pluralityof experts having said particular expertise, wherein the particularexpert is affiliated with at least one of two or more sources ofexpertise previously specified by, or previously specified on behalf of,the requestor.
 9. The method of claim 8 wherein at least two of thesources of expertise are under separate governance from one another. 10.The method of claim 9 wherein at least one of the sources of expertiseis a virtual call center.
 11. The method of claim 9 wherein therequestor is authorized to access the expertise-provisioning system by aparticular system client of the expertise-provisioning system, andwherein at least one of the sources of expertise is an expertise vendorthat has arranged with the system client to have experts of theexpertise vendor included in the plurality of experts.
 12. The method ofclaim 9 wherein the requestor is authorized to access theexpertise-provisioning system by a particular system client of theexpertise-provisioning system, and wherein at least one of the sourcesof expertise is an in-house virtual call center comprising one or moreexperts employed by, or affiliated with, the particular system client.13. The method of claim 8 wherein at least one of the sources ofexpertise is a third-party call center that communicates with theexpertise-provisioning system on behalf of the third-party call center'sexperts.
 14. The method of claim 9 wherein the expertise-provisioningsystem enables available ones the experts communicate directly with theexpertise-provisioning system to indicate a present availability toaccept requests for their expertise from the expertise-provisioningsystem, and wherein the expertise-provisioning system communicatesdirectly with available ones of the experts to notify them of a pendingrequest for which they have been identified as potential suppliers ofthe particular expertise.
 15. The method of claim 14 wherein theexpertise-provisioning system enables the notified experts to indicateacceptance of the pending request, and wherein theexpertise-provisioning system enables the requestor to communicate withan individual one of the experts who has accepted the request.
 16. Themethod of claim 14 wherein said communicating directly with availableones of the experts comprises notifying available experts who areaffiliated with particular ones of the sources of expertise of thepending request, the particular sources of expertise being identified inaccordance with one or more predefined criteria.
 17. The method of claim16 wherein the requestor is authorized to access theexpertise-provisioning system by a particular system client of theexpertise-provisioning system, and wherein at least one of thepredefined criteria is a matching rule specified by the system client.18. The method of claim 14 wherein said communicating directly withavailable ones of the experts includes the steps of notifying availableexperts affiliated with a first source of expertise of the pendingrequest, and notifying available experts affiliated with a second sourceof expertise of the pending request if the expertise-provisioning systemhas not received an acceptance of the request from an expert of saidfirst source of expertise within a predetermined time.
 19. The method ofclaim 9 wherein a proprietor of the expertise-provisioning systemenables each of a plurality of system clients of theexpertise-provisioning system to authorize particular individuals toaccess the expertise-provisioning system in exchange for financialconsideration from said each system client, and an expertise vendorenables at least ones of its experts to be available to accept requestsfrom said particular individuals in exchange for financial considerationfrom said particular system client.
 20. The method of claim 19 whereinthe proprietor of the expertise-provisioning system enables each of aplurality of system clients of the expertise-provisioning system toauthorize particular individuals to access the expertise-provisioningsystem without receiving financial consideration from said expertisevendor, and said expertise vendor enables at least ones of its expertsto be available to accept requests from said particular individualswithout receiving financial consideration from the proprietor of theexpertise-provisioning system.
 21. The method of claim 9 wherein therequestor is authorized to access the expertise-provisioning system by aparticular system client of the expertise-provisioning system, andwherein the two or more sources of expertise are specified by the systemclient.
 22. A method for use in a expertise-provisioning system, themethod comprising receiving a request from a requestor to establish anelectronic communication session with an expert having a particularexpertise specified by the requestor, causing the requester to bepresented with a) at least two options for the electronic communicationsession, and b) for each option, a respective estimated wait time forthe electronic communication session to begin, receiving from therequestor an indication of one of the options, and enabling theelectronic communication session to be established in accordance withthe indicated option.
 23. The method of claim 22 wherein one of theoptions for the electronic communication session is a video session andanother one of the options for the electronic communication session isan audio session.